Conversation
…ead AST code
- Workbench schema endpoint now generates TypeScript interface syntax
from JSON Schema (via runtime toJSONSchema) instead of requiring
Zod source strings from the AST-extracted metadata. Falls back to
metadata strings only when no runtime schema is available.
- Add jsonSchemaToTypeScript() utility in workbench.ts that converts
JSON Schema → clean TypeScript type notation for display:
{ name: string; age: number; tags?: string[] }
- Delete findCreateAppEndPosition() from ast.ts — dead code, exported
but never imported anywhere.
- 20 new tests covering all JSON Schema → TypeScript conversions:
primitives, objects, optionals, descriptions, arrays, unions,
intersections, enums, literals, nullables, records, nested objects.
…hemaToTypeScript Address CodeRabbit review feedback: - Escape quotes, backslashes, and newlines in const/enum string values - Quote property keys that aren't valid JS identifiers (hyphens, spaces, leading digits) - 3 new test cases covering both fixes
Remove 402 lines of dead code from the AST pipeline: - Delete analyzeWorkbench() + parseConfigObject() — only imported by the dead workbench.ts file, never used in production - Delete checkFunctionUsage() — exported but never imported anywhere - Delete checkRouteConflicts() — exported but never imported anywhere - Delete WorkbenchAnalysis interface — only used by dead code - Remove WorkbenchConfig import from ast.ts (no longer needed) - Delete packages/cli/src/cmd/build/workbench.ts entirely — the whole file was dead code (getWorkbench, generateWorkbenchMainTsx, etc. are superseded by vite/workbench-generator.ts) - Remove analyzeWorkbench tests from ast.test.ts (testing dead code) ast.ts: 3,526 → 3,124 lines (402 lines removed, cumulative with previous findCreateAppEndPosition deletion)
The lifecycle generator now uses TypeScript's own type checker to
extract the setup() return type instead of walking AST literals and
guessing types from values. This handles:
- Inline setup in createApp({ setup: () => ... })
- Exported setup functions (function decl or const arrow)
- Shorthand property: createApp({ setup })
- Variable references: setup: () => someVar
- Async functions (Promise unwrapping)
- Any pattern TypeScript itself can resolve
Also extract getDevmodeDeploymentId into ids.ts (pure hash, not AST).
ast.ts consumers remaining: only parseRoute (route-discovery.ts)
…iscovery + app-router-detector
createRouter() no longer wraps Hono methods — it's now just `new Hono()`
with Agentuity's Env type. This preserves Hono's full Schema type inference
chain, enabling `typeof router` to encode all route types.
The routeId lookup (for OTel spans) and returnResponse auto-conversion that
createRouter previously did will move to entry-file middleware in a follow-up.
agent-discovery.ts: rewritten to import() agent files at build time instead
of AST-parsing with acorn-loose. The agent instance already knows its own
metadata, schemas, and evals. Schemas are now extracted as JSON Schema
strings via toJSONSchema() instead of Zod source strings via astring.
app-router-detector.ts: rewritten to use TypeScript's compiler API instead
of acorn-loose. Detects createApp({ router }) patterns for explicit routing.
Both rewrites eliminate acorn-loose/astring usage from their respective files.
Only ast.ts itself still imports acorn-loose (for parseRoute, used by
route-discovery.ts).
Tests: 18 agent-discovery tests, 8 app-router-detector tests, 8 lifecycle
tests, dev-registry-generation tests all pass. Runtime: 665 tests pass.
- Delete ast.ts (3,120 lines) — entire acorn-loose + astring AST pipeline - Delete route-migration.ts (793 lines) — file-based routing migration - Delete api-mount-path.ts (87 lines) — file-based path computation - Remove acorn-loose + astring from package.json - Remove file-based routing fallback from entry-generator.ts - Remove migration prompts from dev/index.ts and vite-bundler.ts - Remove src/api/ directory watcher from file-watcher.ts - Remove migrateRoutes CLI option - Delete 15 test files testing deleted AST/file-based routing code - Rewrite route-discovery + dev-registry tests for new architecture Net: -13,073 lines deleted, +199 lines added
- Import toForwardSlash from normalize-path.ts instead of duplicating
- Replace existsSync with Bun.file().exists() in lifecycle-generator,
app-router-detector, and agent-discovery
- Import toJSONSchema from @agentuity/schema public entry point (resolved
from user's node_modules) instead of reaching into src/ internals
- Remove createAgent substring gate — check exported value shape instead,
supporting re-exported agents
- Default createRouter S generic to BlankSchema ({}) to match Hono 4.7.13
- Migrate integration-suite, e2e-web, svelte-web, auth-package-app,
webrtc-test, nextjs-app, tanstack-start, vite-rsc-app to explicit
createApp({ router }) pattern
- Create combined router.ts files for apps with multiple route files
- Expose agent.evals on AgentRunner (was missing, breaking eval discovery)
- Deduplicate agents by name (re-exported agents from index.ts)
- Update route-metadata-nested tests for explicit routing
…estart loop
- Runtime: createApp() returns fetch/port/hostname for bun --hot to
hot-swap the server's request handler without process restart
- Runtime: skip Bun.serve() in dev mode (bun --hot manages server
via default export)
- Runtime: add idempotent OTel re-registration guard for hot reloads
- Runtime: pass cors/compression config directly to middleware instead
of lazy global lookup via getAppConfig()
- Runtime: remove getAppState/getAppConfig/setAppConfig globals
(config passed directly, app state was always {})
- Runtime: add typed _globals.ts for Symbol.for() state and globals.d.ts
for string-keyed globalThis properties, eliminating unsafe casts
- Runtime: use Symbol.for() pattern in _process-protection.ts
- Runtime: guard one-time log messages (server started, local services)
to prevent reprinting on hot reloads
- Runtime: downgrade internal port messages to debug level
- CLI: use bun --hot --no-clear-screen for backend subprocess
- CLI: remove file-watcher.ts usage, restart loop, stopBunServer,
cleanupForRestart — bun --hot handles all backend HMR
- CLI: run 'Preparing dev server' once at startup instead of on
every file change (~490 lines removed from dev/index.ts)
In production mode, startServer() already calls Bun.serve() on the configured port. Bun v1.2+ also auto-serves when the default export has fetch + port properties (added in c98ce19 for --hot support), causing a second bind attempt and EADDRINUSE. Strip fetch/port/hostname from the returned AppResult in production so only the explicit Bun.serve() is active. Dev mode keeps them for bun --hot auto-serve.
Resolve conflicts: - modify/delete: keep v2's deletions of generated files (app.ts, routes.ts), ast.ts, and route-migration.ts — superseded by v2's import-based architecture - agent-discovery.ts: keep v2's import-based version, port duplicate eval name detection from main (cab51e2) - dev/index.ts: keep v2's bun --hot version — main's file-watcher restart loop fixes (5b7f9b8) don't apply since v2 removed the restart loop Auto-merged from main: - Gateway URL fallback update (agentuity.ai → catalyst.agentuity.cloud) - Windows path fix for AI SDK patches (buildPatchFilter) - Task status aliases, sandbox events, OIDC commands, monitoring - Coder TUI updates, API reference docs, various CLI fixes
Bun --hot creates the server from the default export's properties.
Without the websocket handler, WebSocket upgrades fail with:
'To enable websocket support, set the "websocket" object in Bun.serve({})'
Add websocket from hono/bun to the AppResult (and strip it in
production alongside fetch/port/hostname).
json5 was not declared as a dependency in cli/package.json, causing a type error. Use the existing parseJSONC utility (from utils/jsonc) which handles tsconfig.json comments and trailing commas.
## @agentuity/migrate package (new) A CLI tool to migrate v1 projects to v2: - `npx @agentuity/migrate` — guided migration with codemods - Deletes `src/generated/` directory - Removes `bootstrapRuntimeEnv()` call from app.ts - Transforms routes from createRouter() mutable style to new Hono<Env>() chained - Generates src/api/index.ts and src/agent/index.ts barrels - Adds migration comments for setup/shutdown lifecycle - Guides on agentuity.config.ts deprecation - Detects frontend using removed APIs (createClient, useAPI, RPCRouteRegistry) - Runs bun install and typecheck post-migration ## agentuity.config.ts deprecation - New app-config-extractor.ts extracts analytics/workbench from createApp() - config-loader.ts emits deprecation warning when loading agentuity.config.ts - getWorkbenchConfig() now prefers runtime config from createApp() - dev/index.ts and vite-builder.ts use loadRuntimeConfig() Config consolidation in v2: - Runtime config (analytics, workbench, cors, etc.) → createApp() only - Vite config (plugins, define, render, bundle) → vite.config.ts - agentuity.config.ts → deprecated, delete entirely ## Documentation - Updated migration-guide.mdx with v1→v2 tab - Includes automated migration instructions and manual steps - Covers all breaking changes and troubleshooting
This commit consolidates several v2 improvements: ### bun-dev-server error diagnostics - Add app.ts validation to detect v1 pattern (destructuring without export default) - Capture Bun stderr/stdout and show in error messages - Add port cleanup with ensurePortAvailable() to kill orphan processes - Warn before starting if app.ts has common issues - Export validation functions for testing ### Process manager for dev mode - New ProcessManager class to track all spawned processes/servers - Ordered cleanup (LIFO for processes) - Force kill fallback after timeout - Integrated into dev/index.ts for cleanup on failure/shutdown ### Remove agentuity.config.ts support - Deleted loadAgentuityConfig from config-loader.ts - getWorkbenchConfig now only takes (dev, runtimeConfig) - no config file fallback - Users must use vite.config.ts for Vite config - Users must use createApp() for runtime config (workbench, analytics) ### Remove auto-adding React plugin - Vite no longer auto-adds @vitejs/plugin-react - Users must configure frontend framework in vite.config.ts ### Deprecate @agentuity/react - Added deprecation notice to README.md and package.json - @agentuity/auth no longer depends on @agentuity/react - AuthProvider now accepts callback props instead of relying on AgentuityProvider ### Migrate tool updates - Detect missing vite.config.ts when frontend exists - Detect deprecated @agentuity/react API usage - Detect agentuity.config.ts and suggest migration Tests: Updated workbench tests, removed define-config test (obsolete), added process-manager tests
Tests verify: - publicDir is set correctly in dev mode config - Public files are served at root paths in dev - Public files maintain directory structure - Various file types are handled correctly - Edge cases (empty folder, hidden files, subdirectories) - Integration with vite-builder functions
Add tests for dev server orchestration covering: - dev-lock.test.ts: Lockfile management, orphan process cleanup, edge cases for corrupted/missing lockfiles - ws-proxy.test.ts: Front-door TCP proxy routing decisions, error handling, URL parsing, query strings - dev-server-integration.test.ts: Full lifecycle testing, crash recovery, hot reload validation, error resilience All 60 tests pass covering: - Startup/shutdown with port cleanup - Hot reload behavior (Bun --hot, Vite HMR) - Crash recovery (SIGTERM/SIGKILL escalation) - WS proxy routing (HTTP→Vite, WS upgrade→Bun) - Error resilience (TypeScript errors, v1 patterns)
Merge main (1.0.54) into v2 branch. Resolution strategy: - Deleted files (v2): Kept v2's removal of src/generated/*, ast.ts, route-migration.ts - Dev server files: Kept v2's no-bundle architecture with bun --hot - Package versions: Took main's higher versions - New features from main: Accepted (oauth, sandbox jobs, service packages) - API docs: Took main's updated documentation Key changes merged from main: - New standalone service packages (@agentuity/db, @agentuity/email, etc.) - OAuth service support - Sandbox job commands - Updated CLI commands for all cloud services - API reference documentation updates
Since React is no longer auto-added by the CLI, each project with a frontend needs its own vite.config.ts with the appropriate plugins. Added vite.config.ts for: - apps/docs (React + Tailwind + MDX + TanStack Router) - apps/testing/e2e-web (React) - apps/testing/cloud-deployment (React) - apps/testing/integration-suite (React) - apps/testing/auth-package-app (React) - apps/testing/oauth (React) - apps/testing/webrtc-test (React) - apps/testing/svelte-web (Svelte - pending investigation for CLI build) Updated vite-builder.ts to properly merge user vite.config.ts: - User plugins now come FIRST (important for framework plugins like Svelte) - User config values are preserved unless overridden by Agentuity-specific needs - Removed mergeConfig in favor of explicit spread to avoid array merge issues Note: Svelte builds work with vite v8.0.1 building client environment for production... �[2K transforming...✓ 1 modules transformed. but fail when built through the CLI. This requires further investigation into how the Svelte plugin interacts with the CLI's build process.
…lity ## Problem Svelte 5 builds failed when invoked through CLI's programmatic viteBuild() call, but worked correctly with `bunx vite build`. The error showed the Svelte compile plugin receiving already-compiled JavaScript instead of Svelte source code. ## Root Cause Bun's module loading system has issues with Vite's plugin pipeline when importing Vite and calling build() programmatically. Certain plugins like @sveltejs/vite-plugin-svelte receive already-compiled code, possibly due to module state caching or transformation order issues. ## Solution For client builds, spawn `bun x vite build` as a subprocess instead of importing Vite and calling build() programmatically. This gives Vite complete control over its module loading and plugin execution, avoiding Bun's module system entirely. Workbench builds continue using programmatic viteBuild() since those use our own React plugin without external framework plugins. ## Additional Changes - Updated vite.config.ts for all test projects to include root and input path (required when spawning vite as subprocess) - Updated svelte-web agentuity.config.ts to v2 format (removed plugins) - Removed temporary svelte.config.js that was added during debugging ## Testing All test projects now build successfully: - apps/testing/e2e-web (React) - apps/testing/svelte-web (Svelte 5) - apps/testing/cloud-deployment (React) - apps/testing/integration-suite (React) - apps/testing/auth-package-app (React) - apps/testing/oauth (React) - apps/testing/webrtc-test (React)
The migrate package was missing from the root tsconfig.json references, causing it to not be built during CI builds.
The evals package depends on @agentuity/runtime and @agentuity/schema but was missing the TypeScript project references, causing build failures.
Since the CLI now spawns vite as a subprocess for client builds, projects need a vite.config.ts file with the proper input path. Added: - templates/_base/vite.config.ts with React plugin and input path - vite and @vitejs/plugin-react to devDependencies in package.json
When vite.config.ts sets root='.' and input='src/web/index.html', vite outputs the HTML at client/src/web/index.html instead of client/index.html. The runtime now checks both locations. This fixes cloud deployment tests that were failing because the analytics beacon injection couldn't find the HTML file.
tsgo (@typescript/native-preview) is not available as a standalone npm package. Use standard tsc for CI builds.
Main added new files in areas v3 deleted (runtime, vite pipeline, templates, dev process-manager). These weren't caught by modify/delete conflict resolution since they were new additions on main. Removed: - runtime: bootstrap.ts, globals, handlers, version-check, tests - cli: vite/ws-proxy.ts, dev/process-manager.ts - templates: leaked _base and default files
- Restore telemetry/logger.ts to pre-merge version (main added _globals import from runtime which we deleted) - Remove dev test files brought back by main (dev-lock, dev-server-integration, process-manager, ws-proxy) Build: clean. Tests: 621 pass, 3 fail (coder-related pre-existing).
…t warnings - Add hono, local, stream to root tsconfig.json references (fixes missing dist/ in smoke test) - Switch stream package from tsgo to tsc for consistency with root tsc --build - Remove dead scaffold files in e2e-web and integration-suite (referenced non-existent modules) - Fix lint warnings: unused constructor, unused variables/parameters
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/testing/integration-suite/src/index.ts`:
- Around line 68-71: The file currently uses a default export of an object
containing port and fetch; change this to named exports instead by exporting the
port variable and the fetch handler directly (e.g., export const port = port;
export const fetch = app.fetch) or export the app and/or fetch symbol as named
exports (referencing port and app.fetch in the module), and update any import
sites to use named imports rather than a default import.
- Line 66: The PORT parsing currently uses parseInt(process.env.PORT || '3000',
10) which can produce NaN if process.env.PORT is non-numeric; change the logic
around the const port declaration to parse the env value and fall back to 3000
when the parsed result is NaN (e.g., parse then test Number.isNaN(parsed) and
assign 3000 if invalid) so that the exported port is always a valid number;
update the declaration named port accordingly to ensure downstream code receives
a numeric port.
- Around line 32-64: Import StructuredError from '@agentuity/core' and define a
module-level InvalidRequestError =
StructuredError('InvalidRequestError','Invalid request body'); then wrap every
call to c.req.json() in the handlers for '/api/kv/set', '/api/vector/upsert',
'/api/vector/search', and '/api/queue/publish' in a try-catch that validates
required fields (e.g., key & value for the kv set handler, body.id for vector
upsert, query for vector search, etc.); on parse/validation failure throw
InvalidRequestError({ cause: err }) to normalize malformed payloads to a 4xx
structured error, and also validate the route param in '/api/kv/get/:key' and
throw InvalidRequestError if the key param is missing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3d3cbed8-8ad9-4c40-8de9-2bdfaceda317
📒 Files selected for processing (5)
apps/docs/src/agent/email/agent.tsapps/testing/integration-suite/src/index.tsapps/testing/integration-suite/tsconfig.jsonapps/testing/nextjs-app/package.jsonapps/testing/svelte-web/package.json
✅ Files skipped from review due to trivial changes (1)
- apps/docs/src/agent/email/agent.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Package Installation & Usage Test
- GitHub Check: Framework Demo Tests
- GitHub Check: Sandbox CLI Tests
- GitHub Check: Pack & Upload
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
Use Biome as code formatter with tabs (width 3), single quotes, semicolons, lineWidth 100, and trailingCommas es5
Files:
apps/testing/integration-suite/src/index.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx}: Use TypeScript Strict mode with ESNext target and bundler moduleResolution
UseStructuredErrorfrom@agentuity/corefor error handling
Files:
apps/testing/integration-suite/src/index.ts
**/index.ts
📄 CodeRabbit inference engine (AGENTS.md)
Use named exports from package
index.tsfiles
Files:
apps/testing/integration-suite/src/index.ts
🧠 Learnings (1)
📚 Learning: 2025-12-21T00:31:41.858Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 274
File: packages/cli/src/cmd/build/vite/server-bundler.ts:12-41
Timestamp: 2025-12-21T00:31:41.858Z
Learning: In Bun runtime, BuildMessage and ResolveMessage are global types and are not exported from the bun module. Do not import { BuildMessage } from 'bun' or similar; these types are available globally and should be used without import. This applies to all TypeScript files that target the Bun runtime within the repository.
Applied to files:
apps/testing/integration-suite/src/index.ts
🔇 Additional comments (1)
apps/testing/integration-suite/src/index.ts (1)
18-28: Clean lightweight service-info and health endpoints.The root metadata and health response shape are clear and practical for integration smoke checks.
- e2e-web: switch build/start to Bun target (was incorrectly targeting Node) - e2e-web: include test dir in tsconfig for typecheck coverage - integration-suite: add parseJson helper for error handling on c.req.json() - integration-suite: harden PORT parsing with NaN fallback - integration-suite: add named exports alongside default export - integration-suite: switch build/start to Bun target
- AGENTS.md: add try/catch/finally to handleSubmit example - agent-pulse: remove raw error details from API response - streaming: validate model type at runtime instead of type assertion - vector-storage: return 400 on invalid JSON body - vector-storage: return 503 when vector service unavailable
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
apps/docs/src/api/streaming/route.ts (1)
29-33:⚠️ Potential issue | 🟡 MinorGuard
bodyshape before accessing.model.This still assumes object-like JSON. If payload is
nullor a primitive, property access can throw and drop into the generic stream error path. Validate payload shape first and return400for invalid JSON bodies.🔧 Proposed fix
try { const body = await c.req.json(); - const model = - typeof (body as { model?: unknown }).model === 'string' - ? (body as { model: string }).model - : 'gpt-5-nano'; + if (body === null || typeof body !== 'object' || Array.isArray(body)) { + return c.json({ error: 'Invalid JSON body' }, 400); + } + const payload = body as Record<string, unknown>; + const model = typeof payload.model === 'string' ? payload.model : 'gpt-5-nano';🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docs/src/api/streaming/route.ts` around lines 29 - 33, Validate the parsed request body before accessing .model: after calling c.req.json() (the body variable) check that body is a non-null object (typeof body === 'object' && body !== null) and only then read body.model as a string to set model (otherwise fall back to 'gpt-5-nano'); if the parsed JSON is a primitive or null, respond with a 400 Bad Request instead of proceeding to the streaming logic so property access cannot throw and hit the generic stream error path.apps/testing/integration-suite/src/index.ts (2)
79-82:⚠️ Potential issue | 🟡 MinorDrop the default export from this
index.ts.This file already exposes
portandfetchas named exports, so keeping the default object export preserves two import styles for the same entrypoint and still violates the package export rule.As per coding guidelines,
**/index.ts: Use named exports from packageindex.tsfiles.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/testing/integration-suite/src/index.ts` around lines 79 - 82, This file currently exports a default object containing port and fetch in addition to their named exports; remove the default export so only named exports remain. Locate the export default { port, fetch } and delete it (leaving the existing named exports for port and fetch intact) to comply with the package index.ts rule and avoid exposing two import styles.
19-24:⚠️ Potential issue | 🟠 MajorUse
StructuredErrorhere and validate required request fields.
parseJson()now centralizes syntax parsing, but it still throws a plainError, and these handlers still accept missingkey/value/id/queryas successful requests. That leaves malformed input as either an implicit 500 or a false-positive 200 instead of a normalized 4xx.As per coding guidelines,
**/*.{ts,tsx}: UseStructuredErrorfrom@agentuity/corefor error handling.Also applies to: 41-72
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/testing/integration-suite/src/index.ts` around lines 19 - 24, The parseJson function currently throws a plain Error on JSON parse failure and leaves endpoint handlers accepting missing required fields; replace the thrown Error with a StructuredError (imported from `@agentuity/core`) and set an appropriate 4xx status (e.g., 400) with the original error as the cause, and then update the request handlers that call parseJson (those validating key, value, id, query) to explicitly validate required fields after parsing and throw StructuredError(400, ...) when any required field is missing so malformed input yields normalized client errors rather than 500/200 responses.
🧹 Nitpick comments (2)
apps/docs/.agents/agentuity/sdk/web/AGENTS.md (2)
61-72: Error handling successfully added.The try/catch/finally pattern correctly prevents
isLoadingfrom remaining stuck and addresses the previous review feedback. The finally block ensures cleanup happens in both success and error cases.For additional educational value, consider demonstrating the "Handle loading and error states in UI" best practice (line 340) by adding an error state and displaying it to the user.
📚 Optional enhancement to demonstrate error state UI pattern
function HelloForm() { const [name, setName] = useState('World'); const [greeting, setGreeting] = useState<string | null>(null); const [isLoading, setIsLoading] = useState(false); + const [error, setError] = useState<string | null>(null); const handleSubmit = async () => { setIsLoading(true); + setError(null); try { const res = await client.api.hello.$post({ json: { name } }); const data = await res.json(); setGreeting(data.greeting); } catch (error) { console.error('API call failed:', error); + setError('Failed to get greeting. Please try again.'); } finally { setIsLoading(false); } }; return ( <div> <input type="text" value={name} onChange={(e) => setName(e.target.value)} disabled={isLoading} /> <button onClick={handleSubmit} disabled={isLoading} > {isLoading ? 'Running...' : 'Say Hello'} </button> + {error && <div style={{ color: 'red' }}>{error}</div>} <div>{greeting ?? 'Waiting for response'}</div> </div> ); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docs/.agents/agentuity/sdk/web/AGENTS.md` around lines 61 - 72, Add an error state and surface it in the UI: introduce a state variable (e.g., error / setError) alongside setIsLoading and setGreeting, clear it at the start of handleSubmit, set it inside the catch block with the caught error (or a friendly message), and render the error message in the component (near where greeting is shown) so users see failures; ensure you still call setIsLoading(false) in finally and clear the error when a new submit begins.
231-234: Add error handling for consistency with best practices.The
handleProcessfunction lacks error handling, which is inconsistent with both theHelloFormexample (lines 61-72) and the documented best practice "Handle loading and error states in UI" (line 340). If the API call fails, theresultstate will remain in its previous state without any user feedback.🛡️ Suggested improvement for consistency
const handleProcess = async () => { - const res = await client.api.process.$post({ json: { name: 'Jeff', age: 30 } }); - setResult(await res.json()); + try { + const res = await client.api.process.$post({ json: { name: 'Jeff', age: 30 } }); + setResult(await res.json()); + } catch (error) { + console.error('API call failed:', error); + setResult({ error: 'Failed to process request' }); + } };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docs/.agents/agentuity/sdk/web/AGENTS.md` around lines 231 - 234, The handleProcess function currently calls client.api.process.$post and sets result without handling failures or loading state; update handleProcess to mirror HelloForm by adding local loading and error state management (e.g., setLoading, setError), wrap the await client.api.process.$post call in try/catch, setResult on success, setError on failure and clear loading in finally, and ensure any existing result is not misleading by resetting or indicating loading while the request runs; reference the handleProcess function and result state updates when making these changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/docs/src/api/vector-storage/route.ts`:
- Around line 32-33: Replace ad-hoc error objects in this route with
StructuredError instances: import StructuredError from '@agentuity/core', define
module-level error constructors like const InvalidJSONError =
StructuredError('InvalidJSONError', 'Invalid JSON body') (and similar for other
error cases referenced at lines ~36, 52, 65), then in validation checks and
catch blocks (e.g., the branch that currently returns c.json({ success: false,
error: 'Invalid JSON body' }, 400)) instantiate and return the appropriate
StructuredError (preserving HTTP status codes) so responses use the
StructuredError shape (including the _tag) and telemetry metadata consistently
across vector-storage route and analogous API routes.
In `@apps/testing/integration-suite/src/index.ts`:
- Around line 27-32: The root route handler (app.get('/', (c) => { ... })) and
the other stub handlers (lines ~41-73) return fabricated metadata instead of
exercising the real service clients; update these routes to import and
instantiate the actual clients (e.g., `@agentuity/keyvalue`, `@agentuity/vector`,
`@agentuity/queue`, email, schedule, task) and perform simple health/operation
calls (e.g., ping/get-empty/list) to confirm each package works, then build the
JSON response from those live call results (or mark services as unavailable on
error) so the root metadata accurately reflects which services are actually
exercised by the integration suite. Ensure errors from each client call are
caught and included in the response (or used to set a failing status) rather
than returning hard-coded service names.
---
Duplicate comments:
In `@apps/docs/src/api/streaming/route.ts`:
- Around line 29-33: Validate the parsed request body before accessing .model:
after calling c.req.json() (the body variable) check that body is a non-null
object (typeof body === 'object' && body !== null) and only then read body.model
as a string to set model (otherwise fall back to 'gpt-5-nano'); if the parsed
JSON is a primitive or null, respond with a 400 Bad Request instead of
proceeding to the streaming logic so property access cannot throw and hit the
generic stream error path.
In `@apps/testing/integration-suite/src/index.ts`:
- Around line 79-82: This file currently exports a default object containing
port and fetch in addition to their named exports; remove the default export so
only named exports remain. Locate the export default { port, fetch } and delete
it (leaving the existing named exports for port and fetch intact) to comply with
the package index.ts rule and avoid exposing two import styles.
- Around line 19-24: The parseJson function currently throws a plain Error on
JSON parse failure and leaves endpoint handlers accepting missing required
fields; replace the thrown Error with a StructuredError (imported from
`@agentuity/core`) and set an appropriate 4xx status (e.g., 400) with the original
error as the cause, and then update the request handlers that call parseJson
(those validating key, value, id, query) to explicitly validate required fields
after parsing and throw StructuredError(400, ...) when any required field is
missing so malformed input yields normalized client errors rather than 500/200
responses.
---
Nitpick comments:
In `@apps/docs/.agents/agentuity/sdk/web/AGENTS.md`:
- Around line 61-72: Add an error state and surface it in the UI: introduce a
state variable (e.g., error / setError) alongside setIsLoading and setGreeting,
clear it at the start of handleSubmit, set it inside the catch block with the
caught error (or a friendly message), and render the error message in the
component (near where greeting is shown) so users see failures; ensure you still
call setIsLoading(false) in finally and clear the error when a new submit
begins.
- Around line 231-234: The handleProcess function currently calls
client.api.process.$post and sets result without handling failures or loading
state; update handleProcess to mirror HelloForm by adding local loading and
error state management (e.g., setLoading, setError), wrap the await
client.api.process.$post call in try/catch, setResult on success, setError on
failure and clear loading in finally, and ensure any existing result is not
misleading by resetting or indicating loading while the request runs; reference
the handleProcess function and result state updates when making these changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b3dbf8d0-0b38-4373-819b-6467ce18b1ef
📒 Files selected for processing (8)
apps/docs/.agents/agentuity/sdk/web/AGENTS.mdapps/docs/src/api/agent-pulse/route.tsapps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.tsapps/testing/e2e-web/package.jsonapps/testing/e2e-web/tsconfig.jsonapps/testing/integration-suite/package.jsonapps/testing/integration-suite/src/index.ts
💤 Files with no reviewable changes (1)
- apps/docs/src/api/agent-pulse/route.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/testing/e2e-web/tsconfig.json
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Framework Demo Tests
- GitHub Check: Sandbox CLI Tests
🧰 Additional context used
📓 Path-based instructions (5)
apps/docs/**/*.ts
📄 CodeRabbit inference engine (apps/docs/AGENTS.md)
Use Bun CLI directly from local packages via
bun ../../packages/cli/bin/cli.tsinstead of installing from npm
Files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.ts
apps/docs/src/api/**/*.ts
📄 CodeRabbit inference engine (apps/docs/AGENTS.md)
API routes in src/api/ must support multiple communication patterns: REST, streaming, Server-Sent Events (SSE), and WebSocket using Hono framework
Files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
Use Biome as code formatter with tabs (width 3), single quotes, semicolons, lineWidth 100, and trailingCommas es5
Files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.tsapps/testing/integration-suite/src/index.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx}: Use TypeScript Strict mode with ESNext target and bundler moduleResolution
UseStructuredErrorfrom@agentuity/corefor error handling
Files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.tsapps/testing/integration-suite/src/index.ts
**/index.ts
📄 CodeRabbit inference engine (AGENTS.md)
Use named exports from package
index.tsfiles
Files:
apps/testing/integration-suite/src/index.ts
🧠 Learnings (3)
📚 Learning: 2025-12-19T14:19:33.765Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 259
File: packages/cli/src/cmd/build/vite/registry-generator.ts:306-312
Timestamp: 2025-12-19T14:19:33.765Z
Learning: Route files under src/api should use the .ts extension only (no .tsx) and regex patterns for such paths should anchor to \.ts$ (e.g., /\/.ts$/). Agent files may support both .ts and .tsx, but route files in the Agentuity SDK codebase are restricted to .ts. This guideline applies to all similar route files under src/api across the repository.
Applied to files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.ts
📚 Learning: 2025-12-21T00:31:41.858Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 274
File: packages/cli/src/cmd/build/vite/server-bundler.ts:12-41
Timestamp: 2025-12-21T00:31:41.858Z
Learning: In Bun runtime, BuildMessage and ResolveMessage are global types and are not exported from the bun module. Do not import { BuildMessage } from 'bun' or similar; these types are available globally and should be used without import. This applies to all TypeScript files that target the Bun runtime within the repository.
Applied to files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.tsapps/testing/integration-suite/src/index.ts
📚 Learning: 2026-02-25T22:13:01.823Z
Learnt from: Huijiro
Repo: agentuity/sdk PR: 1063
File: apps/testing/vite-rsc-app/agentuity/src/api/index.ts:26-26
Timestamp: 2026-02-25T22:13:01.823Z
Learning: Agentuity SDK requires default exports for API route files (e.g., src/api/**/index.ts and src/api/**/route.ts) because the CLI's generateRouteRegistry relies on default exports to discover routes. Using named exports will skip route generation and lead to runtime 500 errors. This overrides typical guidance about named exports in index.ts files; ensure a default export is present in all relevant API route files under src/api/**/.
Applied to files:
apps/docs/src/api/streaming/route.tsapps/docs/src/api/vector-storage/route.ts
🔇 Additional comments (4)
apps/testing/e2e-web/package.json (2)
2-2: Cleanup matches the new Bun/Hono scope.The package rename and trimmed dependency set line up with this app’s new role as a lightweight Bun-backed test server rather than a React/Vite app.
Also applies to: 15-19
8-12: Bun runtime wiring is now consistent.These scripts now match
apps/testing/e2e-web/src/server.ts, which exports a Bun-style{ port, fetch }server, and they resolve the earlier Node/Bun startup mismatch cleanly.apps/docs/src/api/vector-storage/route.ts (2)
27-33: Good malformed-JSON handling inPOST /search.This correctly prevents parser exceptions from surfacing as 500s and returns a clear 400 response instead.
51-53: Correct service-availability guard before vector search.The Line 51 pre-check plus direct call on Line 56 now avoids reporting success when
c.var.vectoris absent.Also applies to: 56-56
| return c.json({ success: false, error: 'Invalid JSON body' }, 400); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify current error-handling pattern consistency in docs API routes.
rg -n --type=ts -C2 'StructuredError|return c\.json\(\{ success:\s*false,\s*error:' apps/docs/src/apiRepository: agentuity/sdk
Length of output: 1764
🏁 Script executed:
# Check if StructuredError is used anywhere in the API routes
rg -n 'StructuredError' apps/docs/src/api --type=tsRepository: agentuity/sdk
Length of output: 39
🏁 Script executed:
# Look at the full context of the vector-storage route to understand the structure
head -70 apps/docs/src/api/vector-storage/route.tsRepository: agentuity/sdk
Length of output: 1968
🏁 Script executed:
# Check what's exported from `@agentuity/core` related to error handling
fd core packages -type d | head -5Repository: agentuity/sdk
Length of output: 227
🏁 Script executed:
# Search for StructuredError in the entire codebase
rg 'StructuredError' --type=tsRepository: agentuity/sdk
Length of output: 36858
🏁 Script executed:
# Find the `@agentuity/core` package and look for error handling
find packages -name '*core*' -type dRepository: agentuity/sdk
Length of output: 95
🏁 Script executed:
# Look for error handling patterns in `@agentuity/core`
find packages -path '*core*' -name '*.ts' -type f | head -10Repository: agentuity/sdk
Length of output: 375
🏁 Script executed:
# Check the StructuredError definition to understand how to use it with JSON responses
head -100 packages/core/src/error.tsRepository: agentuity/sdk
Length of output: 2857
🏁 Script executed:
# Look for all API route files in apps/docs/src/api
find apps/docs/src/api -name '*.ts' -type fRepository: agentuity/sdk
Length of output: 973
🏁 Script executed:
# Check if any other docs API routes use StructuredError
rg -l 'StructuredError' apps/docsRepository: agentuity/sdk
Length of output: 177
🏁 Script executed:
# Check how StructuredError is used in docs-orchestrator.ts for reference
grep -A5 -B5 "StructuredError\|Base64DecodeError" apps/docs/src/agent/doc_processing/docs-orchestrator.ts | head -30Repository: agentuity/sdk
Length of output: 961
🏁 Script executed:
# Check the RichError/StructuredError methods to understand serialization
sed -n '100,200p' packages/core/src/error.tsRepository: agentuity/sdk
Length of output: 3216
🏁 Script executed:
# Look at more API routes to understand current error patterns
head -80 apps/docs/src/api/chat/route.tsRepository: agentuity/sdk
Length of output: 678
🏁 Script executed:
# Check if there are any examples of StructuredError being used with c.json in Hono
rg -B10 -A5 'c\.json' packages/core/src --type=ts | grep -A10 -B10 'StructuredError\|return c\.' | head -50Repository: agentuity/sdk
Length of output: 1179
🏁 Script executed:
# Look for error handling middleware or patterns in runtime/Hono context
find packages -name '*runtime*' -o -name '*hono*' | grep -E '\.(ts|tsx)$' | head -5Repository: agentuity/sdk
Length of output: 248
🏁 Script executed:
# Get more context on the full structure of StructuredError to understand JSON serialization
sed -n '140,250p' packages/core/src/error.tsRepository: agentuity/sdk
Length of output: 2963
🏁 Script executed:
# Check if there's any error handling middleware in the docs app or runtime
rg -n 'onError|middleware|catch' packages/core/src/services --type=ts | head -20Repository: agentuity/sdk
Length of output: 1679
🏁 Script executed:
# Look at the index.ts in docs API to see if there's error handling setup
cat apps/docs/src/api/index.tsRepository: agentuity/sdk
Length of output: 1922
🏁 Script executed:
# Check if there are any Hono middleware examples in the codebase
rg -B5 -A10 '\.use\(' apps/docs/src/api --type=ts | head -50Repository: agentuity/sdk
Length of output: 1019
🏁 Script executed:
# Check if there are any examples of error handling in other doc API routes
head -60 apps/docs/src/api/database/route.tsRepository: agentuity/sdk
Length of output: 509
🏁 Script executed:
# Verify the full picture: check if StructuredError is exported in index from core
grep -A2 "StructuredError" packages/core/src/index.tsRepository: agentuity/sdk
Length of output: 152
🏁 Script executed:
# Look at how StructuredError instances are actually serialized in JSON
cat > /tmp/test_structured_error.ts << 'EOF'
import { StructuredError } from '@agentuity/core';
const InvalidJSONError = StructuredError('InvalidJSONError', 'Failed to parse JSON')<{ details?: string }>();
const err = new InvalidJSONError({
message: 'Invalid JSON body',
details: 'Unexpected token'
});
console.log(JSON.stringify(err, null, 2));
EOFRepository: agentuity/sdk
Length of output: 39
🏁 Script executed:
# Check a few more API routes to get a broader picture of the error handling inconsistency
rg -n 'return c\.json.*success.*false' apps/docs/src/api --type=tsRepository: agentuity/sdk
Length of output: 1570
Implement StructuredError for consistent error handling across API routes.
Per coding guidelines, all error handling must use StructuredError from @agentuity/core. The vector-storage route currently returns ad-hoc error objects that should be replaced with structured error instances.
Define error types at the module level (e.g., const InvalidJSONError = StructuredError('InvalidJSONError', 'Invalid JSON body')) and instantiate them in catch blocks and validation checks. This ensures consistent error shape, enables proper telemetry metadata, and provides runtime type discrimination via the _tag property.
Also applies to: 36, 52, 65, and similar patterns in other API routes (queue, key-value, etc.)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/docs/src/api/vector-storage/route.ts` around lines 32 - 33, Replace
ad-hoc error objects in this route with StructuredError instances: import
StructuredError from '@agentuity/core', define module-level error constructors
like const InvalidJSONError = StructuredError('InvalidJSONError', 'Invalid JSON
body') (and similar for other error cases referenced at lines ~36, 52, 65), then
in validation checks and catch blocks (e.g., the branch that currently returns
c.json({ success: false, error: 'Invalid JSON body' }, 400)) instantiate and
return the appropriate StructuredError (preserving HTTP status codes) so
responses use the StructuredError shape (including the _tag) and telemetry
metadata consistently across vector-storage route and analogous API routes.
| app.get('/', (c) => { | ||
| return c.json({ | ||
| name: 'integration-suite', | ||
| description: 'Agentuity services integration tests', | ||
| services: ['keyvalue', 'vector', 'queue', 'email', 'schedule', 'task'], | ||
| }); |
There was a problem hiding this comment.
These routes are still stubs, so the “integration suite” is not exercising the service packages.
Every service endpoint here returns fabricated data and never instantiates or calls the clients added in package.json. That means this app can stay green while @agentuity/keyvalue, @agentuity/vector, or @agentuity/queue are broken, and the root metadata currently overstates coverage for email, schedule, and task.
Also applies to: 41-73
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/testing/integration-suite/src/index.ts` around lines 27 - 32, The root
route handler (app.get('/', (c) => { ... })) and the other stub handlers (lines
~41-73) return fabricated metadata instead of exercising the real service
clients; update these routes to import and instantiate the actual clients (e.g.,
`@agentuity/keyvalue`, `@agentuity/vector`, `@agentuity/queue`, email, schedule, task)
and perform simple health/operation calls (e.g., ping/get-empty/list) to confirm
each package works, then build the JSON response from those live call results
(or mark services as unavailable on error) so the root metadata accurately
reflects which services are actually exercised by the integration suite. Ensure
errors from each client call are caught and included in the response (or used to
set a failing status) rather than returning hard-coded service names.
- Remove wait_for_server calls for agent ports 3500/3501/3502 (no apps start agent servers) - Fix Next.js dev port: 3000 → 3001 to match Playwright config baseURL - Guard Vite RSC section: skip if apps/testing/vite-rsc-app doesn't exist - Clean up agent ports from cleanup function The framework test apps are scaffolds without agent backends. The Playwright tests still need the apps to be built out to pass, but the script will no longer timeout waiting for nonexistent servers.
The staggered ports (3000/3001/3002) and agent ports (3500/3501/3502) were from the old v2 architecture with separate agent runtime servers. In v3, apps are plain framework apps running sequentially, so they all use the default port 3000. - Next.js dev: 3001 → 3000 - Playwright config: all baseURLs → localhost:3000 - Test script: all wait/cleanup on port 3000 only
The wildcard export ("./*") works in workspace mode but fails when
packages are installed from tarballs (CI smoke test). Add explicit
exports and typesVersions entries for all 24 service directories
(apikey, auth, coder, db, email, eval, keyvalue, machine, monitoring,
oauth, org, project, queue, region, sandbox, schedule, session,
storage, stream, task, thread, user, vector, webhook, workflow).
Keeps the wildcard as a fallback for any future services.
Fixes: oauth test "Cannot find module '@agentuity/core/oauth'"
|
Found 3 test failures on Blacksmith runners: Failures
|
The testing apps (oauth, e2e-web, integration-suite) import from @agentuity/core subpaths which resolve to dist/ files. Without building packages first, these imports fail with 'Cannot find module'. Every other CI job that runs tests (sandbox-cli, queue-sdk, queue-cli, framework-demo) already has a 'bun run build' step.
The previous tanstack-start was a plain Vite+React app with no actual TanStack Start setup (missing @tanstack/react-start, router plugin, app.config, __root.tsx, routeTree). Replaced with a proper TanStack Start app created via @tanstack/cli: - File-based routing with router plugin + auto-generated routeTree - SSR with @tanstack/react-start - Tailwind CSS v4 - Proper vite.config.ts with tanstackStart() plugin Also updated Playwright e2e tests to match actual app content instead of speculative echo demo UI that never existed. - biome: exclude routeTree.gen.ts from linting (auto-generated) - Suppress dangerouslySetInnerHTML warning in __root.tsx (SSR pattern)
- Add @agentuity/core and @agentuity/react to tanstack-start app - Switch test script from 'bun run dev' to 'agentuity dev' (local CLI) so tests exercise the actual Agentuity developer experience with AI Gateway env injection - Add test credentials setup to framework-demo-test CI job (same pattern as build, sandbox-cli, queue-cli jobs)
Add a server-side AI SDK call to exercise the Agentuity AI Gateway integration end-to-end: - Server function using 'use server' directive for TanStack Start RPC - Calls generateText() with @ai-sdk/openai through the gateway - Simple translate UI: text input, language select, translate button - Playwright test verifies the full flow (submit → AI response) When running via 'agentuity dev', OPENAI_API_KEY and OPENAI_BASE_URL are auto-injected so the AI SDK routes through the Agentuity gateway without needing separate provider API keys.
Restyle the TanStack Start test app to match the original Agentuity template dark theme: - Dark background with Agentuity brand cyan accent colors - Same Agentuity logo SVG, font styling, and layout - Translation form with inline language/model selects (not dropdowns) - Glowing translate button with cyan/blue/purple gradient - Results with token count, model, and language metadata - Loading ellipsis animation on the translate button - 'How it works' section with green checkmark list Removed TanStack template components (Header, Footer, ThemeToggle) and light theme CSS in favor of the Agentuity dark theme.
The shellComponent renders the <html>/<head>/<body> document wrapper which includes <HeadContent /> — responsible for injecting the CSS link tag. Without it, the stylesheet never loads.
Replace raw OpenAI SDK usage with the Vercel AI SDK pattern
(ai + @ai-sdk/openai) across all framework scaffolding templates:
- generateText() instead of openai.chat.completions.create()
- Cleaner API: destructure { text } directly
- Consistent with the TanStack Start test app pattern
- Dependencies: 'openai' → ['ai', '@ai-sdk/openai']
Updated frameworks: Next.js, Nuxt, Remix, SvelteKit, Astro, Hono,
Vite+React
Split the 619-line frameworks.ts into three focused files: - frameworks.ts (223 lines) — types + catalog configuration - frameworks-ai-examples.ts (166 lines) — AI SDK example generators - frameworks-landing-pages.ts (267 lines) — Agentuity-branded landing pages The landing pages replace the old brandSnippet approach (which just created a floating badge component that was never auto-injected). Now each framework's default page is replaced with a full Agentuity-branded dark theme welcome page featuring: - Agentuity logo + 'Welcome to Agentuity' heading - Framework name + 'AI Gateway' subtitle - Getting started steps with framework-specific file paths - 'Powered by Agentuity' badge Updated: scaffold.ts brandSnippet → landingPage
The dev command's injectGatewayEnv() requires AGENTUITY_SDK_KEY to be set in order to inject OPENAI_API_KEY/OPENAI_BASE_URL for AI Gateway routing. But it only checked process.env, never loading from the project's .env/.env.development/.env.local files where the key is typically stored after 'agentuity project import'. Now calls loadProjectSDKKey() to read from .env files before injecting gateway env vars, matching how other CLI commands resolve the SDK key.
The dev command now resolves the SDK key in this order: 1. AGENTUITY_SDK_KEY in process.env 2. AGENTUITY_SDK_KEY in project .env files 3. CLI auth api_key from the user's configured profile When falling back to the auth key (#3), shows a warning: 'No linked Agentuity project found. Using your auth key for AI Gateway.' 'Run agentuity project import to link this project for full functionality.' This lets authenticated users use agentuity dev with AI Gateway routing immediately, without needing to create/link a project first.
New script scripts/test-dev.sh that starts each framework testing app through the Agentuity CLI dev command and verifies it responds on port 3000. Exercises framework detection, AI Gateway env injection, and SDK key resolution. Tests: tanstack-start, nextjs-app, vite-react-app Usage: bun run test:dev (all) or bash scripts/test-dev.sh --app tanstack-start
Update framework testing apps so 'bun run dev' runs through agentuity dev, which handles framework detection and AI Gateway env injection automatically: - tanstack-start: dev → agentuity dev --script dev:start - nextjs-app: dev → agentuity dev --script dev:start - vite-react-app: dev → agentuity dev --script dev:start Each app keeps its framework command as dev:start, and the dev script wraps it via the CLI. Added @agentuity/cli as workspace devDependency so the bin is available in bun run scripts. Simplified test-framework-demos.sh and test-dev.sh to just use 'bun run dev' since the scripts now handle the CLI wrapping.
The dev command now: 1. Loads the CLI profile config to get overrides.transport_url and overrides.catalyst_url, injecting them into the child env so the gateway URL resolves correctly (was falling back to default URL even when the profile had region-specific URLs configured) 2. Shows visible status: 'AI Gateway: routing LLM requests through Agentuity' when injection succeeds, or a warning if no API keys are available 3. Returns boolean from injectGatewayEnv for status reporting
TanStack Start uses createFileRoute with a server.handlers property
for API endpoints, not the 'use server' module directive pattern.
Replaced:
- src/server/translate.ts ('use server' module) → src/routes/api/translate.ts (server route)
- src/server/debug.ts ('use server' module) → src/routes/api/debug-env.ts (server route)
Both now use createFileRoute('/api/...') with server.handlers.POST/GET
which is the correct TanStack Start server route pattern.
Frontend calls /api/translate and /api/debug-env via fetch().
AI Gateway env injection confirmed working. Remove the temporary debug-env API route and server environment debug panel from the UI.
Use colorPrimary + bullet instead of muted text so the 'agentuity project import' command stands out in the terminal.
colorPrimary was just white text on dark terminals — barely visible. Switch to colorInfo (cyan) + bold for the 'agentuity project import' command, and use arrow instead of bullet for visual hierarchy.
The framework's own output (e.g. 'VITE v7.3.2 ready in 731 ms') already shows what's running. No need to duplicate with 'Starting dev server (vite) on port 3000' and '$ bun run dev:start'.
Summary
This PR introduces a new modular architecture for Agentuity, breaking the "batteries included"
@agentuity/runtimeinto composable packages. The goal is to let users choose their framework while Agentuity provides services as middleware.What Changed
New Packages
@agentuity/otel@agentuity/local@agentuity/services@agentuity/honoagentuity()middleware for HonoArchitecture
Usage
Completed Migrations
@agentuity/otelwithregisterOtel(), Logger@agentuity/core(removed duplicate)@agentuity/localwith Bun SQLite + runtime detectionagentuity()composes OTel + servicescreateApp()warns usersStrategic Questions (Open for Discussion)
These are fundamental architectural decisions that need community/team input:
1. Agent Orchestration: Build vs Integrate?
Current state:
@agentuity/runtimehas its owncreateAgent()with:ctx.invoke())Options:
@agentuity/agentsQuestions:
2. Conversation/Chat: Build vs Integrate?
Current state:
packages/runtime/src/session.ts(~2000 lines) with:Thread,SessionmanagementThreadProvider,SessionProviderinterfacesOptions:
@agentuity/chatKey consideration: Thread/Session has Hono-specific code (cookies, context). Extracting requires making Hono a peer dependency.
Questions:
3. Agent Evaluation System
Current state:
@agentuity/evalspackage with:EvalRunEventProvider(now in@agentuity/services)Options:
@agentuity/evalsQuestions:
4. Framework Adapters
Not started:
@agentuity/next- Next.js middleware@agentuity/express- Express middleware@agentuity/fastify- Fastify middlewareQuestions:
5. Local Services for Non-Bun Runtimes
Current:
@agentuity/localonly supports Bun (SQLite)Potential runtimes:
Questions:
Breaking Changes
This is a v3 breaking change with no backward compatibility guarantees:
createApp()is deprecated (will be removed)@agentuity/runtimeinternals will breakc.varin HonoDecision Timeline
@agentuity/agentsLooking for feedback on:
Summary by CodeRabbit
Chores
New Features